This Paee is Inserted by IFW Indexing and Scanning 
XerSl" * «•» » f tte ReC ° rd 
BEST AVAILABLE IMAGES 

documents submitted by the applicant. 

• i ^» w ar*» not limited to the items checked: 
Defects in the images include but are not umixeu iu 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES' , 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: . ■ ■ ~~ 



IMAGES ARE BEST AVAILABLE COPY. . 

As rescanning these documents will not correct the .mage 

problems checked, please do not report these problems to 

the IFW Image Problem Mailbox. 




(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
3 May 2001 (03.05.2001) 




PCT 



(10) International Publication Number 

WO 01/31888 Al 



(51 > International Patent Classification 7 : H04L 29/06 

(21) International Application Number: PCT/US00/4121 1 

(22) International Filing Date: 18 October 2000 (18.10.2000) 



(25) Filing Language: 

(26) Publication Language: 



English 



English 



(30) P riori ty Data: 

09/426,614 



26 October 1999 (26. 10.1 999) US" 



(63) Related by continuation (CON) or continuation-in-part 
(CIP) to earlier application: 

US 09/426,614 (CON) 

Bled on 26 October 1999 (26.10.1999) 

(71) Applicant (for all designated States except US)x 3COM 
CORPORATION [US/US]; 5400 Bayfront Plaza, Santa 
Clara, CA 95052 (US). 

\ (72) Inventors; and 

: (75) Inventors/Applicants (for US only)-. BORELLA, 

i Michael, S. [US/US]; 1208 Haverhill Circle, Naperville, 

j IL 60563 (US). GRABELSKY, David, A. [US/US1; 3800 

j Lee Street, Skokie, IL 60076 (US). 



(74) Agent: LESAVICH, Stephen; McDonnell Boehnen 
Hulbert & Berghoff, 32nd floor, 300 South Wucker Drive, 
Chicago, IL 60606 (US). 

(81) Designated States (national^ AE, AG. AL, AM, AT, AU, 
AZ, BA, BB, BG, BR. BY. BZ, CA, CH. CN, CR, CU, CZ. 
DE, DK. DM, DZ, EE, ES, FI, GB, CD, GE, GH, GM, HR. 
HU, ID. IL, IN, IS, JP, KE, KG, KP, KR, KZ. LC, LK, LR, 
LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, 
NO. NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL r TJ, TM, 
TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA. ZW. 

(84^ Designated States (regionaljr~\Rl?0 > ^nt (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZWj, Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE), OAPl patent (BE BJ, CF, CG, 
CI, CM, GA, GN, GW, ML, MR, NE. SN, TD, TG). 

Published: 

— With international search report. 

— Before the expiration of the time limit for amending the 
claims and to be republished in the event of receipt of 
amendments. 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



1= (54) Title: METHOD AND SYSTEM FOR DUAL-NETWORK ADDRESS UTILIZATION BY VIRTUAL TUNNELING 



126 



L 



128 



130 



132 



| IPv6 LOCAL TUNNEL HEADER \ IPv4 HEADER l DATA PAYT-OAD 



CO 
00 
00 



O 



(57) Abstract: A method and system for dual network address utilization. The methods and system descnbed herein may help 
the transition from Internet Protocol version-4 ("IPv4") networks to Internet Protocol version-6 ("IPv6") networks. Dual address 
allocation on IPv4 (50) and/or IPv6 (88) network addresses is provided via a dual protocol stack. Network o^vice^may c^ujucate 
with legacy IPv4 networks while using IPv6 network addresses on an IPv6 network for local communications. IPv6 (U_) over IPv4 
( 1 20) remote virtual tunnels are used to allow network devices using IPv6 network addresses on a local IPv6 network to communicate 
with remote IPv6 networks over IPv4 public networks <e.g., the Internet). IPv4 (130) over IPv6 (128) local virtual tunnels may be 
used to allow network devices to using IPv4 network addresses on a local IPv6 network to communicate with remote ^public 
networks The IPv4 addresses allocated include IPv4 addresses that may be allocated and used for Distributed Network Address 
Translation ("DNAT") and/or the Realm Specific Internet Protocol fRSlP")- The method and system can be used with virtually any 
set of networks that requires transitions between X-bit and Y-bit network addresses and dual network address utilization. 




PCT/US00/41211 



WO 01/31888 



METHOD AND SYSTEM FOR DUAL-NETWORK ADDRESS UTILIZATION BY VIRTUAL TUNNELING 

FIELD OF INVENTTON 
This invention relates to computer networks. More specifically, it relates to a 
method and system for dual network address utilization. 



The Internet Protocol ("IP") is an addressing protocol designed to facilitate the 
routing of traffic within a network or between networks. The Internet Protocol is 
used on many computer networks including the Internet, intranets and other networks. 
Current versions of Internet Protocol such as Internet Protocol version-4 ("IPv4") are 
becoming obsolete because of limited address space. With a 32-bit address-field, it is 
possible to assign 2 32 different addresses, which is 4,294,967,296, or greater than 4 
billion globally unique addresses. 

However, with the explosive growth of the Internet and intranets, Internet 
Protocol addresses using a 32-bit address-field may soon be exhausted. Internet 
Protocol version-6 ("IPv6") proposes the use of a 128-bit address-field for Internet 
Protocol addresses. However, a large number of legacy networks including a large 
number of Internet subnets will still be using older versions for Internet Protocol with 
a 32-bit address space for many years to come. As is known in the art, a subnet is 
smaller of part of a larger network using a similar network addressing scheme. 

Network Address Translation ("NAT') has been proposed to extend the 
lifetime of Internet Protocol version 4 by allowing subnets with private Internet 
Protocol addresses to exist behind a single or small number of globally unique 
Internet Protocol addresses (see e.g., Internet Engineering Task Force ("ITEF") RFC 
2663, "DP Network Address Translator ("NAT") Terminology and Considerations," 
by P. Srisuresh and M. Holdrege, August 1999). Each private host uses a single 
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global Internet Protocol address for communication with external networks such as 
the Internet. 

Internally, a subnet may use local private addressing. Local private addressing 
may be any addressing scheme that is different from the public Internet Protocol 
addressing. The local addresses on a subnet are typically not available to the external, 
global Internet. When a device or node using local addressing desires to communicate 
with the external world, its local address is translated to a common external Internet 
Protocol address used for communication with an external network by a network 
address translation device. That is, network address translation allows one or more 
global Internet Protocol addresses to be shared among a larger number of network 
devices using local private addresses. 

There are several problems associated with using network address translation 
to extend the life of the Internet Protocol version-4. Network address translation 
interferes with the end-to-end routing principal of the Internet that recommends that 
packets flow end-to-end between network devices without changing the contents of 
any packet along a transmission route (see e.g., "Routing in the Internet," by C. 
Huitema, Prentice Hall, 1995, ISBN 0-131-321-927). 

Current versions of network address translation replace a local network 
address in a data packet header with an external global network address on outbound 
traffic, and replace an external global network address in a data packet header with a 
local private network address on inbound traffic. This type of address translation is 
computationally expensive, causes security problems by preventing certain types of 
encryption from being used, or breaks a number of existing applications in a network 
that cannot coexist with network address translation (e.g., File Transfer Protocol 
("FTP")). 
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Current versions of network address translation may not gracefully scale 
beyond a small subnet containing a few dozen nodes or devices because of the 
computational and other resources required. Network address translation potentially 
requires support for many different application layer internal network protocols be 
specifically programmed into a translation mechanism such as a network address 
translation router. 

Computational burdens placed on a network address translation router may be 
significant and degrade network performance, especially if several network address 
translation-enabled sub-networks share the same network address translation router. 
In a worst case scenario, a network address translation router translates every inbound 
and data packet. 

Application Layer Gateways ("ALG") have also been used at a border 
between a private network and a public network like the Internet to provide address 
translation. As is known in the art, a gateway is a device that connects two networks 
using different communications protocols so that information can be passed from one 
to the other. A gateway both transfers information and converts it to a form 
compatible with the protocols used by a receiving network. 

However, the Application Layer Gateways complicate the deployment of new 
applications. Sending and receiving systems need to support the new applications, 
and any Application Layer Gateways in a routing path must be able to identify new 
applications to provide network address translation. 

Some of the problems associated with network address translation of private 

network addresses into public network addresses have been overcome with 

Distributed Network Address Translation ("DNAT") described in co-pending 

Applications No. 09/035,600, 09/270,967 and 09/271,025 assigned to the same 
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Assignee as the present application. See also "Distributed Network Address 
Translation", by Michael Borella, David Grabelsky, Hchlaq Sidhu, and Brian Petry, 
IETF Internet Draft, <draft-borella-aatn-dnat-01.txt>, October 1998. Distributed 
Network Address Translation is also called "Realm Specific Internet Protocol" 
("RSIP") by the IETF. For more information on Realm Specific Internet Protocol see 
"Realm Specific EP Framework," by M. Borella and J. Lo, IETF draft, <draft-ieft-nat- 
rsip-framework-02.txt>, October 1999, and "Realm Specific IP: Protocol 
Specification," by M. Borella and J. Lo, IETF draft, <draft-ietf-nat-rsip-protocol- 
02.txt>, August 1999. 

For Distributed Network Address Translation or RealmSpecific Internet 
Protocol, network devices request a set of locally unique ports from a Distributed 
Network Address Translation server or a Realm Specific Internet Protocol server for 
external communications with a public network like the Internet. A network device 
on a private network replaces default or ephemeral ports (e.g_, such as Transmission 
Control Protocol or User Datagram Protocol) with the locally unique ports. The 
network device uses a combination network address including a locally unique port 
and a common external network address (e.g., an IP address) for the Distributed 
Network Address Translation server for communications with the external networks. 
The network devices use private network addresses for local communications on the 
private network. 

A Distributed Network Address Translation server or a Realm Specific 
Internet Protocol server maintains a port-to-private network address table as locally 
unique ports are allocated to network devices. Network devices send data packets to 
external networks using a combination network address including a locally unique 
port and the common external network address via the Distributed Network Address 



WO 01/31888 PCT/tfSOO/41211 

Translation server or Realm Specific Internet Protocol server. For inbound data 
packets from an external network, the Distributed Network Address Translation server 
or Realm Specific Internet Protocol uses the port-to-private network address table to 
route data packets back to the appropriate network device on the private network. 

Distributed Network Address Translation or Realm Specific Internet Protocol 
allows a host to tunnel data packets to/from a network device and a server over a 
virtual tunnel. As is known in the art, a "virtual tunnel" is created by encapsulating a 
data packet inside another data packet. The outer header typically identifies the 
"endpoints" of the tunnel. The inner header typically identifies an original sender and 
recipient of the data. Thus, data packets are not modified between a source and a 
destination using Distributed Network Address Translation or Realm Specific Internet 
Protocol. 

It is becoming commonplace for private stub network or subnets to be 
"multiple address networks." Multiple address networks are networks in which more 
than one type of network address is used. For example, a private subnet may use new 
128-bit Internet Protocol version-6 addresses to communicate internally and may use 
the older 32-bit Internet Protocol version-4 addresses to communicate with external 
networks such as the Internet. 

However, there are a number of problems associated with using Internet 
Protocol version-6 addresses on a private subnet and Internet Protocol version-4 
addresses on public networks like the Internet. One problem is that Internet Protocol 
version-6 subnets and Internet Protocol version-4 subnets can not communicate 
directly with one another without translation of network addresses since Internet 
Protocol version-4 uses 32-bit addresses and Internet Protocol version-6 uses 128-bit 
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addresses. The network address translations required are subject to the network 
address translation problems described above. 

Another problem is that some network devices will support only Internet 
Protocol version-6, others will support only Internet Protocol version-4, and still 
others will support both versions of the Internet Protocol. Network address translators 
have to be provided with information as to which network devices support which 
version of the Internet Protocol to provide network address translation. This 
complicates the deployment of new applications that are used across networks. 

Thus, it is desirable to provide a solution that allows legacy Internet Protocol 
version-4 subnets to be connected to and communicate with newer Internet Protocol 
version-6 subnets. The solution should allow network devices to use any combination 
of Internet Protocol version-6 and/or Internet Protocol version-4 on a subnet with 
limited computational burdens and without complicating deployment of new 
applications. 
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ST TMMARY OF THE INVENTION 

In accordance with preferred embodiments of the present invention, some of 
the problems associated supporting legacy networks are overcome. A method and 
system for dual network address utilization is provided. 

One aspect of the invention includes a method for dual network address 
utilization. A dual protocol stack provides dual address allocation of X-bit and Y-bit 
network addresses (e.g., 128-bit Internet Protocol version-6 and 32-bit Internet 
Protocol version-4 network addresses). Network devices communicate with legacy 
Y- bit networks while usin g X-bit ne twork addresses on an X-bit network for local 
communications. X-bit over Y-bit remote virtual tunnels are used to allow network 
devices using X-bit network addresses on a local X-bit network to communicate with 
remote X-bit networks over Y-bit networks (e.g., the Internet). Y-bit over X-bit local 
virtual tunnels may be used to allow network devices to using Y-bit network 
addresses on a local X-bit network to communicate with remote Y-bit networks. The 
Y-bit addresses allocated include Y-bit addresses may also used for the Distributed 
Network Address Translation protocol and/or the Realm Specific Internet Protocol. 

Another aspect of the invention includes a system for dual network address 
utilization. The dual network address system includes a multiple network devices 
including a dual protocol stack and a virtual tunnel gateway. The dual protocol stack 
includes a first portion for networking protocols using X-bit network addresses and a 
second portion for networking protocols using Y-bit network addresses. The virtual 
tunnel gateway is used for adding a remote tunnel header for a remote virtual tunnel 
for a data packet with a header including X-bit network addresses sent from a local 
network by a local network device using X-bit network addresses across an 
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intermediate network using Y-bit network addresses to a remote network device on a 
remote network using X-bit network addresses. The virtual tunnel gateway is also 
used for removing a local tunnel header including X-bit network addresses for a data 
packet with a header including Y-bit network addresses and for transmitting the data 
packet with the header including Y-bit network address across the intermediate 
network using Y-bit network addresses. 

The methods and system described herein may help the transition from 
Internet Protocol version-4 ("IPv4") networks to Internet Protocol version-6 ("IPv6") 
networks. However, the present invention is not limited to such an embodiment, and 
can be used with virtually any set of networks that require transitions between X-bit 
and Y-bit network addresses and dual network address utilization. 

The foregoing and other features and advantages of a preferred embodiment of 
the present invention will be more readily apparent from the following detailed 
description. The detailed description proceeds with references to the accompanying 
drawings. 



WO 01/31888 PCT/US00/4121 1 

BRIEF DESCRIPTION OF TTTR DRAWINGS 
Preferred embodiments of the present inventions are described with reference 
to the following drawings, wherein: 

FIG. 1 is a block diagram illustrating an exemplary network system; 
FIG. 2 is a block diagram illustrating a protocol stack for a network device; 
FIG. 3 is a block diagram illustrating an exemplary dual network address 
utilization system; 

FIG. 4 is a block diagram illustrating an exemplary dual protocol stack; 
FIGS. 5A and 5B are a flow diagram illustrating a method for dual network 
address utilization; 

FIG. 6 is a block diagram illustrating an exemplary X-bit to Y-bit network 
address data packet; and 

FIG. 7 is a block diagram illustrating an exemplary Y-bit to X-bit network 
address data packet. 



DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 



Exemplary network system 

FIG. 1 is a block diagram illustrating an exemplary network system 10 

for one preferred embodiment of the present invention. The network system 10 

includes a first computer network 12 with multiple network devices (14, 16, 1 8, 20, 

22) and a router 26 to route data packets to another external computer network. The 

multiple network devices include any of computers (14, 18), printers 16, personal 

digital assistants 20, telephones 22, or other hand-held devices or other network 

devices that can be connected to the first computer network 12. The first computer 

netw6rkT2 mayalso iiKlude^D^amic^ Host Configuration Protocol ("DHCP") 

server 24. As is known in the art, the Dynamic Host Configuration Protocol is a 

protocol for dynamically passing network addresses such as Internet Protocol 

addresses and configuration information to network devices on a network. For more 

information on DHCP see IETF RFC-1 541, and RFC-213 1 and RFC-2132, 

incorporated herein by reference. 

The first computer network 12 has an external common network address 28 

(e.g., a global Internet Protocol version-4 address, 198.10.20.30) to identify the first 

computer network 12 to an external computer network such as a second computer 

network 30 and/or a third computer network 32 external to the first private computer 

network-x 12. The multiple network devices (14, 16, 18, 20, 22, 24 and 26) have a 

local network address (e.g., an Internet Protocol version-6) on the first computer 

network 12. In one preferred embodiment of the present invention, a network access 

service provider 34 with a router 36 routes data packets to/from the first computer 

network 12 a to second computer network 30 and/or to a third computer network 32 

through a second network switch 38 and/or a third network switch 40. In another 
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embodiment of the present invention, the first computer network 12 is connected 
directly to the second computer network 30. The first computer network 12 is also 
connected to a second computer network 42 via computer networks 30 or 32. The 
second computer network 42 is also a computer network that includes multiple 
network devices (not illustrated in FIG. 1) that use local internal network addresses 
(e.g., Internet Protocol version-6 addresses) behind a public globally routable network 
address of (e.g., a global Internet Protocol version-4 address 192.200.20.3). 

In one preferred embodiment of the present invention, the first computer 
network 12 is a Small Office/Home Office ("SOHO") Local Area Network ("LAN"), 
also called a "legacy" LAN. The first computer network 12 can also be a "stub" 
network or a sub-network ("subnet"). As is known in the art, a "stub" network is an 
end or terminal network. As is known in the art, a "subnet" is a smaller part of a 
larger network that uses a common addressing scheme (e.g., Internet Protocol 
addresses). The second network 30 is the Internet or an intranet, using Internet 
Protocol version-4 network addresses and the third network 32 is a Public Switched 
Telephone Network ("PSTN"). The second network-y 42 is also a SOHO LAN, stub 
network or subnet. However, other network types and network components can also 
be used and the present invention is not limited to the network types and network 
components described for this preferred embodiment. 

Network devices and routers for preferred embodiments of the present 
invention include network devices that can interact with network system 10 and 
network system 68 (FIG. 3) discussed below that are compliant with all or part of 
standards proposed by the Institute of Electrical and Electronic Engineers ("IEEE"), 
International Telecommunications Union-Telecommunication Standardization Sector 

("ITU"), Internet Engineering Task Force ("IETF"), the Wireless Application 
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Protocol ("WAP") Forum, and Data-Over-Cable-Service-Interface-Specification 
("DOCSIS") standards for Multimedia Cable Network Systems ("MCNS"). 
However, network devices based on other standards could also be used. IEEE 
standards can be found on the World Wide Web at the Universal Resource Locator 
("URL") "www.ieee.org." The ITU, (formerly known as the CCITT) standards can 
be found at the URL "www.ituxh." IETF standards can be found at the URL 
"www.ietf.org." The WAP standards can be found at the URL 
"www.wapforum.org." The DOCSIS standards can be found at the URL 
"www.cablemodem.com." 

An operating environment for network devices and routers of the present 
invention include a processing system with at least one high speed Central Processing 
Unit ("CPU") and a memory. In accordance with the practices of persons skilled in 
the art of computer programming, the present invention is described below with 
reference to acts and symbolic representations of operations or instructions that are 
performed by the processing system, unless indicated otherwise. Such acts and 
operations or instructions are referred to as being "computer-executed" or "CPU 
executed." 

It will be appreciated that acts and symbolically represented operations or 
instructions include the manipulation of electrical signals by the CPU. An electrical 
system represents data bits which cause a resulting transformation or reduction of the 
electrical signals, and the maintenance of data bits at memory locations in a memory 
system to thereby reconfigure or otherwise alter the CPU's operation, as well as other 
processing of signals. The memory locations where data bits are maintained are 
physical locations that have particular electrical, magnetic, optical, or organic 
properties corresponding to the data bits. 
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The data bits may also be maintained on a computer readable medium 
including magnetic disks, optical disks, organic memory, and any other volatile (e.g., 
Random Access Memory ("RAM")) or non-volatile (e.g., Read-Only Memory 
("ROM")) mass storage system readable by the CPU. The computer readable medium 
includes cooperating or interconnected computer readable medium, which exist 
exclusively on the processing system or be distributed among multiple interconnected 
processing systems that may be local or remote to the processing system. 
Exemplary protocol stack 

FIG. 2 is a block diagram illustrating an exemplary layered protocol stack 44 
for network devices on Internet Protocol version-4 subnets on the exemplary dual 
stack network system 68 (FIG. 3) discussed below. The layered protocol stack 44 is 
described with respect to Internet Protocol suites comprising from lowest-to-highest, a 
link, network, transport and application layer. However, more or fewer layers could 
also be used, and different layer designations could also be used for the layers in the 
protocol stack 44 (e.g., layering based on the Open Systems Interconnection ("OSI") 
model). 

The network devices are connected to a computer network with Network 
Interface Card ("NIC") device drivers in a link layer 46 for the hardware network 
devices connecting the network devices to the computer network 12. The link layer 
44 may include a Medium Access Control ^MAC") protocol layer or other data-link 
layer protocol. 

Above the link layer 48 is a network layer 48 (also called the Internet Layer 
for Internet Protocol suites). The network layer 48 includes an Internet Protocol 
version-4 ("IPv4) layer 50. As is known in the art, IPv4 50 is an addressing protocol 
designed to route traffic within a network or between networks. IPv4 layer 50, 
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hereinafter IPv4 50, is described in IETF RFC-791, incorporated herein by reference. 
The network layer 48 also includes an Internet Group Management Protocol version-4 
("IGMPv4") layer 52, and an optional Internet Control Message Protocol version-4 
("ICMPv4") layer 54. The IGMP v4 layer 52 and the ICMP v4 layer 54 are used with 
IPv4 50. 

ICMPv4 layer 52, hereinafter ICMPv4 52, is used for Internet Protocol 
control. The main functions of ICMPv4 52 include error reporting, reachability 
testing (e.g., "pinging"), route-change notification, performance, subnet addressing 
and other maintenance. For more information on ICMPv4 52 see IETF RFC-792, 
incorporated herein by reference. IGMPv4 layer 54, hereinafter IGMPv4 54, is 
responsible for multicasting. For more information on IGMPv4 54 see IETF RFC- 
1112, incorporated herein by reference. IGMPv4 54 are not both required in the 
protocol stack 44. ICMP v4 52 is often used without IGMPv4 54. 

The network layer 48 may also include an optional Distributed Network 
Address Translation ("DNAT") or Realm Specific Internet Protocol ("RSIP") layer 
55. The DNAT/RSIP layer 55 is used to allocate locally unique ports as well as a 
combination network address including a locally unique port and a common external 
network address (e.g., an IP v4 address) for a DNAT/RSIP server for communications 
with the external networks. For more information on DNAT, see co-pending U.S. 
Application No. 09/035,600 incorporated herein by reference. DNAT is also referred 
to as "Realm Specific Internet Protocol" ("RSIP") by the IETF. For more 
information on RSIP see, "Realm Specific IP Framework," by M. Borella and J. Lo, 
IETF draft, <draft-ieft-nat-rsip-framework-02.txt>, October 1999, "Realm Specific IP: 
Protocol Specification," by M. Borella and J. Lo, IETF draft, <draft-ietf-nat-rsip- 
protocol-02.txt>, August 1999, incorporated herein by reference. 
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Above network layer 48 is a transport layer 56. The transport layer 56 
includes a Transmission Control Protocol ("TCP") layer 58 a User Datagram Protocol 
("UDP") layer 60, and an optional DNAT/RSEP layer 55 described above. The TCP 
layer 58, hereinafter TCP 58, provides a connection-oriented, end-to-end reliable 
protocol designed to fit into a layered hierarchy of protocols which support multi- 
network applications. TCP 58 provides for reliable inter-process communication 
between pairs of processes in network devices attached to distinct but interconnected 
networks. For more information on TCP 58 see IETF RFC-793, incorporated herein 
by reference. 

The UDP layer 60, hereinafter UDP 60, provides a connectionless mode of 
communications with datagrams in an interconnected set of computer networks. 
UDP 60 provides a transaction oriented datagram protocol, where delivery and 
duplicate packet protection are not guaranteed. For more information on UDP 60 see 
IETF RFC-768, incorporated herein by reference. Both TCP 58 and UDP 60 are not 
required in protocol stack 42. Either TCP 58 or UDP 60 can be used without the 
other. 

Above the transport layer 56 is an application layer 62 including application 
programs 64. The application programs 64 provide desired functionality to a network 
device (e.g., telephony or other communications functionality). 
Exemplary dual network address utilization system 

FIG. 3 is a block diagram illustrating an exemplary dual network address 

utilization system 68. The exemplary network utilization system 68 includes an IPv4 

Internet backbone 70, one or more IPv4 only subnets 72, one or more IPv6 only 

subnets 74, and one or more IPv4/IPv6 dual protocol stack subnets 76 and 76' (e.g., 

first network-x 12 or second network-y 42). FIG. 3 illustrates only one IPv4 only 

- 15- 



WO 01/31888 PCT/US00/41211 

subnet 72, only one IPv6 only subnet 74 and two IPv4/LPv6 dual protocol stack 
subnets 74 and 76 for the sake of simplicity. However, the exemplary dual network 
address utilization system 68 typically may include tens or hundreds of such subnets. 
Exemplary IPv4/IPv6 dual protocol stack subnet 76 includes an exemplary first 
network device 78 (e.g., a computer) and an exemplary first virtual tunnel gateway 80. 
Exemplary IPv4/IPv6 dual protocol stack subnet 76' includes an exemplary second 
network device 82 and an exemplary second virtual tunnel gateway 84. Use of 
network devices 78, 82 including a dual protocol stack 86 as is explained below. 

The virtual tunnel gateways 80, 84 are used to create a virtual tunnel. The 
virtual tunnel gateways 80. 84 may also include a DNAT/RSIP server. As is known 
in the an, a gateway is a device that connects networks using different 
communications protocols so that information can be passed from one to the other. A 
gateway both transfers information and converts it to a form compatible with the 
protocols used by the receiving network. 

As is known in the art, a 'Virtual tunnel" can be created by encapsulating a 
data packet inside another data packet For example, an outer header is added before 
an inner header of a data packet. Between the inner header and outer headers are any 
other headers for a data path, or security, such as security headers specific to a tunnel 
configuration. The outer header typically identifies the "endpoints" of the tunnel. 
The inner header typically identifies an original sender and recipient of the data. For 
more information, see "IP-in-IP tunneling,'* by W. Simpson, IETF RFC- 1853, 
October 1995, incorporated herein by reference. However, the present invention is 
not limited this exemplary architecture and more or fewer, and other types of network 
devices and subnet may also be used. 
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In the exemplary network utilization system 68, the IPv4 Internet backbone 70 
connects a number of legacy IPv4 only subnets 72, new IPv6 only subnets 74 and new 
dual protocol stack IPv4/IPv6 subnets 76. Communication over the IPv4 Internet 
backbone between any two subnet uses IPv4 or uses an IPv4 virtual tunnel. Note that 
the IPv4 only subnet 72 and the IPv6 only subnet 74 cannot currently communicate 
directly with each other without some form of direct IPv4-to-IPv6 and IPv6-to-IPv4 
network address translation. 



Exemplary dual protocol stack 

FIG. 4 is a block diagram illustrating an exemplary dual protocol stack 86. 
The dual protocol stack 86 is used on network devices and virtual tunnel gateways on 
dual protocol stack IPv4/IPv6 subnets 76. The dual protocol stack 86 includes a link 
layer 46, a network layer 48, a transport layer 56 and an application layer 62 with the 
protocols described above for the protocol stack 44 illustrated in FIG. 2. 

In addition, the dual protocol stack 86 includes a first IP layer including 32-bit 
versions of IPv4 50, ICMPv4 52. The dual protocol stack 74 also includes a second 
IP layer including 128-bit versions of IPv6 88, and ICMPv6 90. IPv6 88 now 
includes IGMP functionality so, no separate IGMPv6 layer is illustrated. The dual 
protocol stack 86 can send and receive IP data packets with either 32-bit IPv4 
addresses and/or 1 28-bit IPv6 addresses. 

For more information on IPv6 88 see IETF-RFC 2460, "Internet Protocol, 
Version 6 ("IPv6") Specification," by S. Deering and R. Hinden, December 1998, 
incorporated herein by reference. For more information on ICMPv6 90 see IETF- 
RFC 2463, "Internet Control Message Protocol ("ICMPv6") for the Internet Protocol 
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Version 6 ("rPv6") Specification", by A. Conta and S. Deering, December 1998, 
incorporated herein by reference. 

Network devices and virtual tunnel gateways include dual protocol stack 86 on 
dual protocol stack IPv4/EPv6 subnets 76. Network devices on IPv4 only subnets 72 
include protocol stack 44. Network devices on IPv6 subnets 74 only include a 
protocol stack with versions of IPv6 protocols (not illustrated in the FIGs.). 
Dual network address utilization 

FIGS. 5 A and SB are a flow diagram illustrating a Method 94 for dual network 
address utilization. In FIG* 5A at Step 96, a data packet is received in a protocol stack 
on a dual protocol stack on a first network device on a local first network for a second 
network device on a remote second network. The local first network uses X-bit 
network addresses and the remote second network uses X-bit network addresses. The 
local first network is connected to the remote second network by a third network that 
uses Y-bit network addresses. At Step 98, a test is conducted from the protocol stack 
on the dual protocol stack on the first network device to determine whether the data 
packet will use an X-bit network address. 

If the data packet will use an X-bit network address, at Step 100 a first portion 

of the dual protocol stack is selected with a networking protocol using X-bit network 

addresses. At step 102, a header is added to the data packet including X-bit network 

addresses (e.g., X-bit source and destination network addresses). At Step 1 04, the 

data packet is transmitted to a local virtual tunnel gateway on the local first network. 

The local virtual tunnel gateway adds a virtual tunnel header with a Y-bit network 

addresses to the data packet and transmits the data packet to the second network 

device on the remote second network over a remote virtual tunnel via the third 

network that uses Y-bit network addresses. 
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A remote virtual tunnel gateway on the remote second network receives the 
data packet including the tunnel header with the Y-bit network addresses. The remote 
virtual tunnel header removes the tunnel header. The data packet is transmitted to the 
second network device using the X-bit network addresses in the data packet since the 
remote second network uses X-bit network addresses for data packets. 

If the data packet will use is not an X-bit network address at Step 98 of FIG. 
5A, at Step 106 of FIG. 5B a second portion of the dual protocol stack is selected with 
networking protocols using Y-bit network addresses. At step 1 08 a header is added to 
the data packet including Y-bit network addresses (e.g., Y-bit source and destination 
addresses). Step 108 may also include allocating a Y-bit DNAT/RSIP address that is 
added to the header. At Step 1 10, a virtual tunnel header with a X-bit addresses is 
added to the data packet. At Step 1 12, the data packet is transmitted to a local virtual 
tunnel gateway via a local virtual tunnel using the X-bit network addresses in the 
virtual tunnel header. At Step 1 14 the X-bit tunnel header is removed on the local 
virtual tunnel gateway. At Step 1 16, the data packet is transmitted from the local 
virtual tunnel gateway on the local first network to the remote second network over 
the third network using the Y-bit network addresses in the data packet. 

The remote virtual tunnel gateway on the remote second network receives the 
data packet with Y-bit network addresses. The remote virtual gateway adds a tunnel 
header with X-bit network addresses. The data packet is transmitted to the second 
network device on the remote second network using the X-bit network addresses since 
the remote second network uses X-bit network addresses for data packets and the 
original data packet includes Y-bit network addresses. 

In one exemplary preferred embodiment of the present invention Method 94 is 

used with exemplary dual utilization system network 68. However, the present 
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invention is not limited to such an embodiment, and other embodiments can also be 
used. 

In such an exemplary embodiment in FIG. 5 A at Step 96, a data packet is 
received on a dual protocol stack 86 on a first network device 78 on a IPv4/IPv6 dual 
stack subnet 76 for a second network device 82 on a remote second network. The 
remote second network is a IPv6 only subnet 74 or IPv4/IPv6 dual stack subnet 76V 
The exemplary embodiment is illustrated only with respect to the remote IPv4/IPv6 
dual stack subnet 76'. However, the remote second network can also be the IPv6 only 
subnet 74. The local IPv4/IPv6 subnet 76 uses 128-bit IPv6 addresses for local 
network addresses. The remote IPv4/IPv6 subnet 76' also uses 128-bit IPv6 addresses 
for local network addresses. The local dual stack IPv4/IPv6 subnet 76 is connected to 
the remote IPv4/IPv6 subnet 76* by an IPv4 Internet backbone 70 that uses 32-bit IPv4 
addresses. 

At Step 98, a test is conducted from the dual protocol stack 86 to determine 

whether the data packet will use 128-bit IPv6 addresses. If the data packet will use 

128-bit IPv6 addresses, at Step 100 a first portion of the dual protocol stack 86 with 

IPv6 protocols (e.g., 88, 90, 92) is selected. At step 102, a header is added to the data 

packet including 128-bit IPv6 source and destination addresses. At Step 104, the data 

packet with 128-bit IPv6 addresses is transmitted to a local virtual tunnel gateway 80 

on the local dual stack IPv4/IPv6 subnet 76 using the 128-bit IPv6 addresses. The 

local virtual tunnel gateway 80 adds a virtual tunnel header with 32-bit IPv4 source 

and destination addresses by calling the IPv4 portion of the dual protocol stack 86. 

The virtual tunnel gateway 80 transmits the data packet to the second network device 

82 on the remote EPv4/IPv6 subnet 76* over a remote virtual tunnel via the IPv4 

Internet backbone 70 that uses 32-bit IPv4 addresses. On the remote IPv4/IPv6 subnet 
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76', a remote virtual tunnel gateway 84 removes the 32-bit IPv4 tunnel header and 
transmits the data packet to the remote second network device 82 using the original 
128-bit IPv6 network addresses. 

FIG. 6 is a block diagram illustrating an exemplary X-bit to Y-bit network 
address data packet 1 1 8 transmitted at Step 104. The data packet 1 1 8 includes a 
remote virtual tunnel header 120 with a 32-bit IPv4 addresses, a header 122 with 128- 
bit IPv6 addresses and a data pay load 124. 

If the data packet will not use an X-bit network address at Step 98 of FIG. 5A, 
at Step 106 of FIG. 5B a second portion of the dual protocol stack 86 with IPv4 
protocols (e.g., 50, 52, 54) is selected. In one exemplary preferred embodiment of the 
present invention, the 32-bit IPv4 address is a "normal" IPv4 address. In another 
exemplary preferred embodiment of the present invention, the 32-bit IPv4 address is a 
DNAT/RSIP IPv4 combination network address. 

As was discussed above, the DNAT/RSIP combination network address 
includes a locally unique port and a common external network address (e.g., an IPv4 
address) used for DNAT/RSIP. The DNAT/RSIP IPv4 combination network address 
allows a subnet to use a larger number of private network addresses behind a smaller 
number of public network addresses. Step 108 may also include allocating 32-bil IPv4 
DNAT/RSIP addresses that are added to the header. 

At step 108, a header is added to the data packet including a 32-bit IPv4 source 
and destination network address. At Step 1 10, a local virtual tunnel header with a 
128-bit IPv6 source and destination addresses is added to the data packet from the 
IPv4 portion of the dual protocol stack 86 by calling the IPv6 portion of the dual 
protocol stack 86. At Step 1 12, the data packet is transmitted to the local virtual 

tunnel gateway 80 via a local virtual tunnel using the 128-bit IPv6 addresses in the 

-21- 



01/31888 PCT/US00/41211 

virtual tunnel header since the local IPv4/TPv6 subnet 76 uses 128-bit IPv6 addresses. 
At Step 1 14, the 128-bit IPv6 tunnel header is removed on the local virtual tunnel 
gateway 80. At Step 1 16, the data packet is transmitted from the virtual tunnel 
gateway 80 to the second network device 82 on remote second network 76' over the 
IPv4 Internet backbone using the 32-bit IPv4 addresses in the data packet. 

On the remote IPv6/IPv6 subnet 76 1 , the remote virtual tunnel gateway 84 adds 
a tunnel header with a 128-bit IPv6 source and destination address to the data packet 
and transmits the data packet to the second network device 82 since the remote 
IPv4/IPv6 subnet 76' uses 128-bit network addresses for data packets and the original 
data packet includes a 32-bit IPv4 network address. The remote virtual tunnel 
gateway 84 may also use DNAT/RSIP on the data packet to identify the second 
network device and route the data packet to the second network device. 

FIG. 7 is a block diagram illustrating an exemplary Y-bit to X-bit network 
address data packet 126 transmitted at Step 104. The data packet 126 includes a 
remote virtual tunnel header 128 with a 128-bit IPv6 addresses, a header 130 with 32- 
bit IPv4 addresses and a data pay load 132. 

The methods and system described herein may help the transition from IPv4 to 

IPv6 networks. Dual address allocation is provided with a dual protocol stack that 

allows network devices to communicate with legacy IPv4 networks while using IPv6 

for local communications on a IPv6 subnet IPv6 over IPv4 remote virtual tunnels 

may be used to allow network devices using IPv6 network addresses on a local IPv6 

subnet to communicate with remote IPv6 subnets over IPv4 public subnets. IPv4 over 

IPv6 local virtual tunnels may be used to allow network devices to using IPv4 

network addresses on a local IPv6 subnet to communicate with remote IPv4 public 

subnets. The IPv4 addresses allocated may include IPv4 addresses used for the 
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Distributed Network Address protocol Translation and/or the Realm Specific Internet 
Protocol 

It should be understood that the programs, processes, methods, systems and/or 
apparatus described herein are not related or limited to any particular type of 
computer apparatus (hardware or software), unless indicated otherwise. Various types 
of general purpose or specialized computer apparatus may be used with or perform 
operations in accordance with the teachings described herein. While various elements 
of the preferred embodiments have been described as being implemented in software, 
in other embodiments hardware or firmware implementations may alternatively be 
used and visa-versa. 

In view of the wide variety of embodiments to which the principles of the 
invention can be applied, it should be understood that the illustrative embodiments are 
exemplary only, and should not be taken as limiting the scope of the present 
invention. For example, the steps of the flow diagrams may be taken in sequences 
other than those described, and more or fewer elements or component may be used in 
the block diagrams. 

The claims should not be read as limited to the described order or elements unless 
stated to that effect. Therefore, all embodiments that come within the scope and spirit 
of the following claims and equivalents thereto are claimed as the invention. 
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WE CLAIM: 

1 . A method for dual network address utilization, comprising the steps of: 
receiving an data packet in a dual protocol stack on a first network device on a 
local first network for a second network device on a remote second network, wherein 
the local first network uses X-bit network addresses, the remote second network uses 
X-bit network addresses and the local first network is connected to the remote second 
network by a third network that uses Y-bit network addresses; 

determining from the dual protocol stack whether the data packet will use an 
X-bit network address, and if so, 

selecting a first portion of the dual protocol stack including networking 
protocols using X-bit network addresses, 

adding a header with an X-bit network addresses to the data packet, 
transmitting the data packet to a local virtual tunnel gateway on the 
local first network using the X-bit network addresses, wherein the local virtual tunnel 
gateway adds a remote virtual tunnel header with Y-bit network addresses and 
transmits the data packet to the second network device on the remote second network 
over a remote virtual tunnel via the third network that uses Y-bit network addresses; 

determining from the dual protocol stack whether the data packet will use an 
X-bit network addresses, and if not, 

selecting a second portion of the dual protocol stack including networking 
protocols using Y-bit network addresses, 

adding a header with a Y-bit addresses to the data packet, 

adding a local virtual tunnel header with X-bit network addresses to the 

data packet, 
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transmitting the data packet to the virtual tunnel gateway over a local 
virtual tunnel using the X-bit network addresses in the virtual tunnel header, 

removing the X-bit tunnel header on the local virtual tunnel gateway, 

and 

transmitting the data packet from the local virtual tunnel gateway on 
the local first network to the second network device on the remote second network 
over the third network using the Y-bit network addresses in the data packet. 

2. A computer readable medium have stored therein instructions for causing a 
central processing unit to execute the method of Claim 1 . 

3. The method of Claim 1 wherein the local first network and the remote 
second network include any of Internet Protocol version-6 subnets or dual Internet 
Protocol version-4/Intemet Protocol version-6 subnets. 

4. The method of Claim 1 wherein the third network includes an Internet 
Protocol version-4 network. 

5. The method of Claim 4 wherein the third network is the Internet. 

6. The method of Claim 1 wherein the X-bit network address includes a 128- 
bit Internet Protocol version-6 network address and the Y-bit network address 
includes a 32-bit Internet Protocol version-4 network address. 
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7. The method of Claim 1 wherein the first portion of the protocol stack 
includes an Internet Protocol version-6 portion of the protocol stack and the second 
portion of the protocol stack is an Internet Protocol version-4 portion of the protocol 
stack. 

8. The method of Claim 1 wherein the Y-bit network address includes any of 
a Y-bit Distributed Network Address Translation or a Realm Specific Internet 
Protocol network address. 

9. The method of Claim 8 wherein the Y-bit network address includes a 
combination network address including a common public Internet Protocol version-4 
address and a locally unique port used for Distributed Network Address Translation or 
Realm Specific Internet Protocol to uniquely identify the first network device. 

10. The method of Claim 1 wherein the first network device and the second 
network device include any of a computer* printer, personal digital assistant or 
telephone. 



11. The method of Claim 1 further comprising: 

receiving a data packet on a remote virtual tunnel gateway on the remote 
second network with a virtual tunnel header including Y-bit network addresses; 
removing the virtual tunnel header on the remote virtual tunnel gateway; 
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transmitting the data packet to the second network device using X-bit network 
addresses from a header in the data packet, wherein the remote second network uses 
X-bit network addresses for data packets. 

1 2. The method of Claim 1 further comprising: 

receiving the data packet with a header including Y-bit network addresses on a 
remote virtual tunnel gateway on the remote second network; 

adding a virtual tunnel header with X-bit network addresses to the data packet 
on the remote virtual tunnel gateway; 

transmitting the data packet to the second network device using the X-bit 
network addresses in the tunnel header, wherein the remote second network uses X-bit 
network addresses for data packets and the data packet includes a header with Y-bit 
network addresses. 

13. The method of Claim 1 wherein the networking protocols of the dual 
protocol stack include any of Internet Protocol version-4 or Internet Protocol version- 

6. 



14. A dual network address utilization system, comprising in combination: 
a dual protocol stack, wherein the dual protocol stack includes a first portion 

for networking protocols using X-bit network addresses and a second portion for 

networking protocols using Y-bit network addresses; 

a plurality of network devices including the dual protocol stack; 
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a local network using X-bit network addresses; 

a remote network using X-bit network addresses; 

an intermediate network using Y-bit network addresses; 
a virtual tunnel gateway for adding a remote tunnel header for a remote virtual 
tunnel for a data packet with a header including X-bit network addresses sent from a 
local network device on a local network using X-bit network addresses across an 
intermediate network using Y-bit network addresses to a remote network device on a 
remote network using X-bit network addresses for removing a local tunnel header 
including X-bit network addresses for a data packet with a header including Y-bit 
network addresses, and for transmitting the data packet with the header including Y- 
bit network address across the intermediate network using Y-bit network addresses. 

15. The system of claim 14 wherein the X-bit network address is a 128-bit 
Internet Protocol version-6 network address and the Y-bit network address is a 32-bit 
Internet Protocol version-4 network address. 

16. The system of Claim 14 wherein the Y-bit network address includes any 
of a Y-bit Distributed Network Address Translation or a Realm Specific Internet 
Protocol network address. 

17. The system of Claim 16 wherein the Y-bit network address includes a 
combination network address including a common public Internet Protocol version-4 
address and a locally unique port used for Distributed Network Address Translation or 
Realm Specific Internet Protocol to uniquely identify the first network device. 
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1 8. The system of Claim 14 wherein the plurality of network devices include 
any of a computers, printers, personal digital assistants or telephones. 



19. A method for dual network address utilization, comprising the steps of: 
receiving an data packet in a dual Internet Protocol stack on a first network 
device on a local Internet Protocol network for a second network device on a remote 
Internet Protocol network, wherein the local Internet Protocol network uses 128-bit 
Internet Protocol version-6 addresses, the remote second network uses 128-bit Internet 
Protocol Network addresses and the local Internet Protocol network is connected to 
the remote Internet Protocol network by a third Internet Protocol network that uses 
32-bit Internet Protocol addresses; 

determining from the dual Internet Protocol stack whether the data packet will 
use a 128-bit Internet Protocol version-6 address, and if so, 

selecting a first portion of the dual Internet Protocol stack using 128-bit 
Internet Protocol version-6 addresses, 

adding a header to the data packet including a 128-bit Internet Protocol 
version-6 network addresses, 

transmitting the data packet to a local virtual tunnel gateway on the 
local Internet Protocol network using the header with 128-bit Internet Protocol 
version-6 network addresses, wherein the local virtual tunnel gateway adds a remote 
virtual tunnel header including 32-bit Internet Protocol version-4 network addresses 
and transmits the data packet to the second network device on the remote Internet 
Protocol network over a remote virtual tunnel via the third Internet Protocol network 
that uses 32-bit Internet Protocol version-4 addresses; 
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determining from the dual Internet Protocol stack whether the data packet will 
use a 128-bit Internet Protocol version-6 address, and if not, 

selecting a second portion of the dual Internet Protocol stack using 32-bit 
Internet Protocol version-4 addresses, 

adding a header to the data packet including 32-bit Internet Protocol 
version-4 network addresses, 

adding a virtual tunnel header to the data packet including 128-bit 
Internet Protocol version-6 network addresses, 

transmitting the data packet in a local virtual tunnel to the local virtual 
tunnel gateway using the 128-bit Internet SoTocol^ddresses version-6 in the virtual 
tunnel header, 

removing the virtual tunnel header with the 128-bit Internet Protocol 
addresses version-6 on the local virtual tunnel gateway, and 

transmitting the data packet from the local virtual tunnel gateway on 
the local Internet Protocol network to the second network device on the remote 
Internet Protocol network over the third Internet Protocol network using the 32-bit 
Internet Protocol version-4 addresses in the data packet. 

20. A computer readable medium have stored therein instructions for causing a 
central processing unit to execute the method of Claim 19. 

21 . The method of Claim 19 wherein the third Internet Protocol Network is 
the Internet. 
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22. The method of Claim 19 wherein the local Internet Protocol network and 
the remote Internet Protocol network include dual Internet Protocol version-4/Internet 
Protocol version-6 subnets. 

23. The method of Claim 19 wherein the 32-bit Internet Protocol network 
address includes any of a 32-bit Internet Protocol version-4 Distributed Network 
Address Translation network address or a Realm Specific Internet Protocol network 
address. 

24. The method of Claim 23 wherein the 32-bit Internet Protocol network 
address includes a combination network address with a common public Internet 
Protocol version-4 address and a locally unique port used for Distributed Network 
Address Translation or Realm Specific Internet Protocol to uniquely identify the first 
network device. 
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